Cloud-computing environments and enterprise networks may comprise many software applications and utilities that each requires an independent identification or authentication procedure, such as entering a username and password, providing biometric data, or identifying a security image. In cloud, hybrid-cloud, and other complex computing environments, a user may need to access multiple processing environments or domains, each of which may require the user to re-authenticate itself in order to establish a new session. Higher-security applications that automatically log out inactive users may force a user to sign on and re-authenticate several times during what would otherwise be considered a single session.
Single Sign-On (SSO) functionality can simplify these requirements by means of a third-party entity Identity Provider (IDP) charged with authenticating users and then asserting information about authenticated users to Service Providers and other parties operating within the IDP's domain.
In an environment that supports SSO, an IDP need authenticate a user only once. If an authenticated user then requests access to a service provided by a Service Provider (SP) within the IDP's domain, the IDP will forward the user's authenticating or identifying information directly to the Service Provider. This automated background-authentication procedure may be invisible to the authenticated user, who is then allowed access without being required to manually sign on to the service or otherwise undergo an authentication procedure.
SSO capabilities may be “federated” in a multi-domain environment where services are provided by multiple, often unaffiliated, Service Providers. In a Federated SSO (F-SSO) system, an IDP may use data stored on a trusted “federation server” to identify and authenticate a user to Service Providers that span multiple domains.
In such an F-SSO system, a user may thus, after logging in to an IDP's login portal, be automatically identified, authenticated, and authorized to access multiple applications that each reside on a different platform, are launched from unaffiliated domains, are owned or licensed by different companies, or that are each accessed through a different Service Provider.
Such implementations are especially effective when Service Providers, despite each maintaining a trusted relationship with the Identity Provider, cannot directly share confidential user data because they are not in trusted relationships with each other.
Implementing F-SSO functionality can be expensive and complex, but may be cost-effective in environments where implementation costs can be spread across large numbers of users or a small number of federation partners. F-SSO capabilities might, for example, be especially valuable to privileged users like cloud-management personnel and system administrators, who may support on-premises, off-premises, and hybrid cloud environments. F-SSO allows the Identity Provider to retain ownership of these privileged users throughout their user lifecycle, as there is no need for an independent means of authentication of the privileged user a the Service Provider.
However, such users may need to sign on frequently to multiple secured applications managed by multiple entities, satisfy stringent high-security authentication requirements, or log off an application and then sign back on every time a task must be paused or interrupted.
But because a cloud provider may have thousands or tens of thousands of clients, each of which may have relatively few administrators, it may not be cost-effective for the cloud provider to make the necessary changes to its authentication process and enable F-SSO functionality to support F-SSO for the privileged users of the cloud provider's clients.